Two different paradigms are used for the execution of a program (including implementation without limitation in software, firmware, and hardware forms)—synchronous operation and asynchronous operation. Synchronous operation is where the program issues a command, such as to a physical drive, and then keeps checking for the interrupt in the interrupt status register until the presence of the interrupt in the register indicates that the command has completed, either successfully or unsuccessfully, before continuing with the operation of the program. In this case, all of the external commands are accomplished in the same context. For example, a synchronous RAID program waits for the drive to complete its read/write/functional operation before continuing with other operations.
Asynchronous operation is where the program issues a command, such as to a physical drive, and then does not expect the status of the command to be returned prior to proceeding with other operations. In this case, all of the external commands might not be accomplished in the same context. For example, an asynchronous RAID program issues a command to a physical drive, but then does not wait for the interrupt before continuing with other operations. In this case, the program merely expects an interrupt service routine call from the drive sometime after the drive completes its read/write/functional operation.
In RAID driver programs, for example, some tasks are required to be executed in a synchronous mode. A synchronous operation is mainly required during load and shut down, when the upper layers of the operating environment might not provide the multi-threaded execution path that is required for asynchronous operations. Thus, all of the load and unload processes typically complete synchronously. Some drivers are not even allowed to have interrupts at load and unload times, due to environment limitations.
However, during normal run time, a program should function in a asynchronous mode, so as to produce maximum throughput and to reduce system resource usage. Thus, some device drivers implement some commands in synchronous mode and other commands in asynchronous mode, or all commands in both modes depending upon when they are run. For example, some RAID device drivers implement commands in both synchronous mode and asynchronous mode. However, other drivers do not implement any asynchronous commands, but use only synchronous commands.
Unfortunately, drivers that implement both synchronous and asynchronous modules in a standard manner require more time to develop and validate, and tend to be bulky and difficult to manage. Drivers that only utilize synchronous mode tend to be inefficient.
What is needed, therefore, is a system that overcomes problems such as those described above, at least in part.